Benchmark for 03cbd37

See especially this change here: 774fde6

I'm stupid and forgot the discussion we already had about this :)

The only state that needs to be managed here is the random state of the cycle, which actually only is needed when the cycle is seeded. All other state is derived from the cycle's iteration count. So this commit can be removed.

Instead, omit should always increase the cycle iteration count, and seeded cycles should derive the random number generator state from the cycle iteration count once on each new generate call.

Benchmark for 6227750

Benchmark for 1d73755

The random output in the cycle currently has a regression in that it is no longer being deterministic based on the seed, since I've added the proper pattern mult and division.

Seeding once per iteration will still not be deterministic enough if we want to mirror tidalcycles. Here is a quote from my previous comment on this

[[a b] | [c d]]/2

Here tidal will output a single event per cycle, but b will always follow a and d will always follow c since cycles are queried in whole and their randomness is a pure function of the iteration count of the (sub)cycle, the step and the seed.

I've added the step variable to the state (that you are removing here) to prepare for an eventual solution because it is no longer sufficient to have a starting seed as the multiply operator has to sample the subcycle it affects at arbitrary iterations to get the output.

So apart from a top level seed we would need the random generator to be sampled by position instead of just yielding some value when gen_range is called. Ideally we could be able to say rng.sample(iteration + step) where step is the absolute position index of the currently outputting step in the entire pattern or something similar. I might be missing something here but I think this would solve it.

The current behaviour is indeed still not correct (not behaving like the tidal reference implementation), but this is somewhat out of scope here. I would make this a follow-on TODO/PR, okay?

Ideally we could be able to say rng.sample(iteration + step) where step is the absolute position index of the currently outputting step in the entire pattern or something similar.

With the introduction of step, the new advance function will actually have to use a function similar to generate to maintain the step, which will then depend on the random state. That's what confused me at first.

And If we're going to change that, it might be easier and more efficient to use a simpler PRNG, where the state index can be set directly, rather than having to reseed it every time. This should be possible with e.g. a simple Mersenne Twister.

@unlessgames okay for you to close and merge this? Then I can move on from here...

Sounds good! Maybe it will be best to implement this once the last feature for tidal is complete.